feat: Improved memory managment and cleanup#11
Conversation
There was a problem hiding this comment.
Cleaned up my error handling - turns out graphql can accept Error instances as return values, not just when thrown. So this change updates the types to reflect that. This is now the dataloader package handles multiple errors, so this makes it easier to map dataloader outputs to graphql results.
| export type WxtQueueCtx = import("../dependencies").Dependencies; | ||
| export type WxtQueueCtx = { | ||
| deps: import("../dependencies").Dependencies; | ||
| }; |
There was a problem hiding this comment.
I'm now using transient services, so I need to provide the proxy object so they can be instantiated each time they're needed rather than instantiating them once at the beginning.
|
|
||
| export const contextPlugin = createApp() | ||
| .decorate(container.resolveAll()) | ||
| .decorate({ deps: container.registrations }) |
There was a problem hiding this comment.
Here's where I'm actually passing in the proxy object instead of resolving all services once.
There was a problem hiding this comment.
Converted to a class to speed up creating instances of this object now that it's created every request instead of once up top.
In general, singleton objects are faster to create with a factory function once, but classes are faster when they need instantiated multiple times, like on every request.
There was a problem hiding this comment.
Added a simple fetch error to better log errors coming from other APIs
| .register("chromeWebStore", transient(createChromeWebStore)) | ||
| .register("firefoxAddonStore", transient(createFirefoxAddonStore)) | ||
| .register("edgeAddonStore", transient(createEdgeAddonStore)) |
There was a problem hiding this comment.
Registering these as transient means they'll be recreated every time they're accessed. I pulled out the API dependencies so those aren't recreated unnecessarily.
The data loaders inside each still have a cache, but they are no longer long-lived, and expire after each requesst.
Technically, the stores might be created more than once each request if the store is resolved multiple times per-request... they're not, but could be in the future.
The small little machine I'm running this service on is living on the edge at 90% memory usage, and it appears to be because of this service (I host many others as well).
I will increase it's capacity, but also wanted to address some memory management issues:
Honestly, I'm still not sure why this app is taking 0.5GB of memory. There's some small overhead from just running it, but that shouldn't be nearly that much. So I'm just being careful for now.